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Abstract 
This document provides a guideline for creating civic address 
considerations documents for individual countries, as required by RFC 
4776. Furthermore, this document also creates an IANA Registry 
referring to such address considerations documents and registers such 
address considerations for Austria. 

Status of This Memo 


This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5774. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The Presence Information Data Format Location Object (PIDF-LO) 
[RFC4119] is an object format for carrying geographical information 
on the Internet. PIDF-LO can contain civic address information and 
supports a range of "civic address types" (CAtypes) to hold the 
individual attributes of such addresses (see Section 2.2.1 of 
[RFC4119] and Section 3.1 of [RFC5139]). 


In many use cases, PIDF-LOs are populated with data from long- 
established sources, like postal and governmental building registers, 
line information databases and yellow/white pages of infrastructure 
providers, or official residents registers. The structure and format 
of data from such sources is almost always different from PIDF-LO’s 
CAtypes definition -- additionally, the structure and format of those 
sources differ from country to country. 


To make use of such existing data sources, transposing that data into 
PIDF-LO format is required. With no guidelines available on how to 
map source Fields into CAtype Elements, different creators of PIDF-LO 
documents might end up with different results, even when using the 
same data source, which reduces interoperability and increases the 
risk of misinterpretation by recipients. 


Therefore, civic address considerations are necessary to ensure 
uniform usage of PIDF-LO Elements for such data sources. [RFC4776] 
explicitly requests such documents to be provided, but defines 
neither their structure nor a way to publish them. This memo 
provides documentation on how to create such civic address 
considerations, and IANA has created a registry to store references 
to such documents. Furthermore, civic address considerations for 
Austria are provided in Appendix A and have been registered in the 
IANA registry. 


Section 3.4 of [RFC4776] contains some example considerations 
regarding the use of administrative subdivision Elements for Canada, 
Germany, Japan, Korea, and the United States. This document 
registers these examples with IANA as "obsolete" (see Section 6.3). 


Section 3.4 of [RFC4776] also contains instructions on the creation 
of civic address considerations documents on page 8. This document 
updates that section and replaces said instructions with Sections 4 
and 5 of this memo. 


The guidelines in this document have been created with a focus on 
formal application of PIDF-LO (such as conveying location during an 
emergency call). It is not intended to forbid other, more informal 
uses of PIDF-LO that may not follow any formal mapping 
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specifications. An example use case of such informal usage may be 
the transmission of PIDF-LO documents during an instant-messaging 
session between humans. Such use may, however, imply some drawbacks, 
like prohibiting automatic processing of civic addresses from such a 
PIDF-LO. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


In addition, this document uses "Field" to refer to a field of a 
civic address data source, and "Element" to refer to a CAtype Element 
of a PIDF-LO. 


3. Requirements 


The following requirements apply to defining civic-address mapping 
considerations: 


o The considerations document MUST identify the data source to which 
the definitions apply. A brief description of its structure 
SHOULD be provided as well. 


o For any data source, just one active mapping definition should 
exist in order to reduce the risk of ambiguous interpretation. 


o The document MUST include instructions for any Field that occurs 
in the data. For any of the Fields, the document MUST describe 
whether the Field is required, optional, or must not be used in 
the mapping procedure. 


o Instructions MUST be included for any CAtype Element that is 
registered by the time the document is created. Those 
instructions MUST include information regarding whether an Element 
is required, optional, or must not be used in that mapping. In 
Case the set of CAtypes is revised by the IETF, the address 
considerations document SHOULD be updated. Until an update is 
approved, the existing mapping procedure MUST be used. 


o Address mapping procedures SHOULD be reversible so that location 
recipients can identify the corresponding record in the original 
data source (given they have access to that source). 


o For any source data Field that is required or optional, at least 
one example mapping MUST be provided. 
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o In many cases, data sources used in the mapping process might be 


subject to access restrictions. Such restrictions (as imposed on 
the original data) MUST also be imposed on the resulting PIDF-LO 
documents. The considerations document SHOULD note such 


restrictions in its Security Considerations section. 


Although the mapping is defined in a national way and the actual 
meaning of several PIDF-LO Elements may not be clear to an outsider, 
at least the country Element tells in what context this PIDF-LO was 
created. In case of emergency Calls, a PIDF-LO would just be passed 
to a Public Safety Answering Point (PSAP) in the same country as the 
location generator anyway. However, in a border region there might 
be exceptions and the PIDF-LO could be sent to a neighboring country. 
The PIDF-LO can still be passed on to a PSAP in the right country 
(based on the country Element), or the PSAP might be aware of the 
mapping scheme used in the neighboring country. 


A consistent mapping is also very important for checking if two PIDF- 
LO documents describe the same location. When civic address Fields 
are put into different PIDF-LO Elements, it may be difficult to 
identify whether or not two PIDF-LOs describe identical addresses. 


4. Specifying PIDF-LO Element Usage 


The purpose of the civic address considerations for an individual 
data source is to create interoperability by specifying a common list 
of PIDF-LO Elements to be used and by defining the mapping between 
these Elements and the Fields of the respective data source. 


4.1. General Considerations and Workflow 


The workflow for creating an address considerations document is as 
follows: 


1. Describe the data source to which the address considerations 
document applies. 


2. Identify all Fields from the data source and decide, for each of 
the Fields, whether or not it is to be used for the purpose of 
creating PIDF-LO documents. The considerations document must 
list all Fields (or at least state which Fields are considered in 
the mapping and clearly state that the other Fields MUST NOT be 
used). 


3. For each of the Fields that are required or optional, specify a 
clear mapping instruction according to the guidelines below. 
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4. Provide a list of all CAtypes registered and describe their level 
of usage in this mapping (or combine it with the list of Fields 
above and clearly list which Elements are not used for the 
mapping procedure). For Elements that are not described in 
detail, state whether they MUST NOT be used at all or whether 
they may be used without further restriction. 


5. Provide examples of source data and mapping results. 


Civic address Elements are designed to be generic containers. In 
some cases, Fields clearly correspond to such a container; however, 
in some other cases, identifying the correct container might require 
some approximation. For example, in some countries the RD (road) 
Element might also be appropriate for other thoroughfares, like 
waterways or tunnels. 


Fields that are identified to have the same meaning as one of the 
CAtypes SHOULD be directly mapped to that CAtype Element. 


Where CAtype usage diverges from the original specification, the 
mapping definition of Fields that are mapped to that Element SHOULD 
include a discussion of the differences. 


Fields that do not fit into an existing CAtype: 


Even though the list of CAtypes could be extended, it is not 
feasible to add new Elements for every new Field in every data 
source in every country. Therefore, unless new generic CAtypes 
are specified by the IETF, only existing Elements can be used, 
which leaves the following options: 


1. Concatenate several civic address Fields into a single PIDF-LO 
Element (define delimiters if applicable and make sure the 
separate civic address parts can be retrieved again). 


2. Use a PIDF-LO Element that is unused so far. 
Note: Obviously, the first option is required if the number of 
Fields that are used in the mapping procedure is greater than the 


number of existing CAtype Elements. 


Note that the xml:lang attribute should be present in PIDF-LO XML 
[W3C.REC-xm1-20060816] documents, according to RFC 5139. 
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4.2. Guidelines for Individual Elements 


The following sections discuss individual PIDF-LO Elements and 
describe what to consider for each Element when defining civic 
address considerations. It is RECOMMENDED to follow a similar 
structure for considerations documents. 


4.2.1. Country 


The country Element must hold the alpha-2 codes from ISO 3166-1 
[ISO3166-1] in uppercase characters, as clarified in Section 3.3 of 
RFC 5139 [RFC5139]. 


This Element cannot be redefined on a national basis since it 
identifies the country itself. This Element is used to identify 
which national mapping for civic addresses has been used in a 
specific PIDF-LO. 


Example for Austria: <country>AT</country> 
4.2.2. Country Subdivisions Al-A6 


The Elements Al to A6 are used to hold national subdivision 
identifiers, with Al holding the top-level subdivision identifier. 

Al may either contain the second part of ISO 3166-2 [ISO3166-2] (see 
Section 3.4 of RFC 5139 [RFC5139]) or other values as described in 
the particular address considerations document. Elements "A2" to 
"A6" may contain additional levels of subdivisions (see Section 2.2.1 
of RFC 4119). 


For Al, an address considerations document MUST state whether ISO 
3166-2 codes are to be used exclusively; alternatively, it should 
define a list of values to be used (for example, subdivision names). 
In either case, Al MUST NOT be redefined for any other use than 
describing top-level subdivisions. 


For each of the A2 - A6 Elements that are required or optional, the 
document SHOULD define the set of allowed values, either by listing 
them or by referring to such a list. 


Example for Austria: 


Al province (Bundesland) 

A2 political district (politischer Bezirk) name or identifier 

A3 commune (Gemeinde) name or identifier 

A4 village (Ortschaft) name or identifier 

A5 cadastral municipality (Katastralgemeinde) name or identifier 
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A6 must not be used. For more details, see the example in Appendix 
E A 


4.2.3. Road and Street Names 


PIDF-LO contains the following Elements related to road names: RD, 
RDSEC, RDBR, RDSUBADDR, PRM, POM (Sections 3.1 and 3.2 of RFC 5139 
[RFC5139]) and PRD, POD, STS (Sections 3.4 of [RFC4776]). Note: the 
use of the A6 Element for street names is not valid any more (Section 
3.2 of RFC 5139 [RFC5139]). 


Besides the basic specification of which of those Elements are 
required, optional, or not to be used, an address considerations 
document may also describe more complicated dependencies (for 
example, "RD is optional, but required if any other road name Element 
is used"). 


For any required or optional Element, the relation of those Elements 
to Fields of the data source used MUST be described, as should 
special considerations (like concatenation of Fields into an 
Element), if they apply. The usage of the Element STS (street 
suffix) SHOULD be consistent. In case no suffixes are known ina 
data source, or it is common to write the street name and the suffix 
together, the STS Element SHOULD be left out completely. If suffixes 
may be abbreviated, the common abbreviations SHOULD be defined. 


Example for Austria: 

RD: street name 

All other road Elements must not be used. Street suffixes are 
already included in the "street name" Field and must not be 
abbreviated. 


4.2.4. House Numbers 


PIDF-LO specifies two Elements related to house numbers: HNO ("house 


number", numeric part only) and HNS ("house number suffix") (see 
Section 3.4 of RFC 4776). However, in many countries house numbers 
have a more complex format. In any case, a clear definition is 


REQUIRED to minimize the potential for confusion. 


An address considerations document should provide the following 
information with regards to house numbers: if the structure of house 
numbers fits the HNO/HNS structure, the document MUST mandate to use 
those Elements as described in RFC 4776. If the structure of house 
numbers does not directly fit into those two Elements, the document 
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MUST define strategies on how to map source Fields into Elements. 
Besides HNO and HNS, LOC and BLD could be considered for carrying 
house number information. 


The document SHOULD describe whether or not abbreviations of house 
number information is valid. If abbreviations are used, they MUST be 
clearly defined. If house numbers consist of more than one number, 
or if multiple prefixes and suffixes may coexist, a delimiter symbol 
and a clear rule on how to concatenate all this data into the HNO and 
HNS Element might be necessary. Whenever concatenating data into one 
Element, keep in mind that the location recipient might want to 
separate the data again. 


Example from Austria: 


HNO: concatenate all the data Fields of Austrian house numbers into 
this single PIDF-LO Element in a defined order with delimiter 
symbols (see Appendix A.4.4 for the complete definition). 


HNS: usage not allowed since there may be multiple suffixes for the 
different parts of the house number. 


LOC and BLD are not to be used to reflect house number information. 
4.2.5. Local Names 


PIDF-LO contains three Elements to reflect local names: LMK, LOC, and 
NAM (Section 3.4 of RFC 4776). Such local names may be of importance 
for the identification of a location and may either coexist with a 
valid civic address or (in some cases) have no address assigned, in 
which case the local name, itself, identifies the location. In rural 
regions, for example, a farm name may be more common than a street 
address to identify a location. Landmarks typically don’t have any 
civic address information assigned. Therefore, local names may 
assist in finding a "street name" type address, but they might also 
be the authoritative (and only) civic location information. 


For any required or optional Element out of LMK, LOC, or NAM, the 
considerations document should state potential values (source data) 
for the Element. In the case that multiple values for an Element may 
occur, a concatenation/selection strategy should be described. 
Concatenation using ";" as a separator is recommended, unless this 
character also appears in the source Fields. 


If local name information and "common" address information is both 
available and used, the document SHOULD discuss the relationship 
between those two address information types and the expected behavior 
of location recipients. 
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Example from Austria: 


NAM: contains the "Vulgoname" (local name); multiple local names are 
separated by a semicolon (if applicable). 


LMK: contains the farm name (just one name possible) (if applicable). 


LOC: can be used without restriction for additional location 
information (as per RFC 4119). 


The "Vulgoname" is useful to identify the location within its 
locality, since official addresses (especially in rural regions) 
might not be well known. 


4.2.6. Floors 


PIDF-LO defines the Element FLR to hold floor information but does 
not further specify its content. Section 2.1 of RFC 3825 provides 
guidance about floor numbering but is not directly related to PIDF- 
LO. 


An address considerations document SHOULD clearly specify how to 
express floors using the FLR Element. Following the above-mentioned 
guidance is RECOMMENDED; however, local nomenclature might require a 
completely different system. The document SHOULD specify whether 
only numbers, text, or both are allowed in the FLR Element. If there 
are standard values for certain floors, they SHOULD be listed. 
Abbreviations SHOULD be avoided, unless they are the primary (well- 
known) way of identifying floors. 


Example from Austria: 


If floor numbers are to be mapped, the FLR Element MUST be used. 
Numbers and text are both allowed. The first floor (<FLR>1</FLR>) is 
the first "full" floor above the floor at street level. The floor at 
street level is <FLR>EG</FLR> or <FLR>0</FLR>. There might be 
intermediate floors, especially between the floor at street level and 


the "first floor". Such intermediate floors have names like 
"Mezzanine", "Erster Halbstock" ("first half floor"), or "Zweiter 
Halbstock" ("second half floor"), and have local meanings. 


4.2.7. Address Codes 


Address codes are available in several countries in different forms 
(for estates, buildings, or usable units for example). These codes 
identify an address record and MAY be placed in the ADDCODE Element 
in PIDF-LO. Address codes can help the location recipient to 
determine the location and to identify the original record in the 
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ler 


data source. Depending on the type of code, the code alone (without 
any other Elements) may even be sufficient to fully identify an 
address within a country. 


In such cases, a PIDF-LO containing just the country and ADDCODE 
Elements might provide enough information to retrieve a civic 
address, given the location recipient has access to the respective 
source database. 


A civic address considerations document SHOULD specify whether and in 
which applications the use of the ADDCODE Element is allowed. If 
ADDCODE is used, its relation to the remaining Elements MUST be 
clearly stated. If several namespaces for address codes exist in a 
country, a mechanism to distinguish the different code spaces MUST be 
described. 


Examples from Austria: 

Statistik Austria provides 4 codes: Adresscode (AdrCD), Adresssubcode 
(AdrsubCD), Objektnummer (ObjNr), and Nutzungseinheitenlaufnummer 
(NtzLnr). 


The following format SHOULD be used: 


<ADDCODE>AdrCD=1234567; AdrsubCD=123; 
Ob jJNr=2333211; Nt zLnr=0001</ADDCODE> 


8. Other Elements 


This section lists all PIDF-LO Elements that have not been discussed 
so far. 


To specify the location inside a building, the following Elements can 
be useful: 


o UNIT 
o ROOM 
o SEAT 


The following Elements are to be used for the representation of 
postal codes: 


o PC 
o PCN 
o POBOX 
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To describe the place-type or the building, the following Elements 
are available: 


o PLC - Place-type (for allowed values, refer to the IANA registry 
defined in [RFC4589]) 


o BLD - Building (structure) 


For any of those Elements that are required or optional in a mapping, 
the semantics of its contents must be described if it differs from 
the definition in the PIDF-LO base documents. 


It is RECOMMENDED that the Elements SEAT, UNIT, and ROOM remain to be 
used for identifying a location inside a building. They MAY be used 
by the owner of the respective building if a considerations document 
does not restrict their use. For example, an airport could decide to 
place the gate number in the UNIT Element and a location recipient 
could identify that PIDF-LO by the value of the PLC Element. The 
name of the airport could be placed in NAM. 


5. Security Considerations 


RFC 4119 contains general security considerations for handling PIDF- 
LOs. 


6. IANA Considerations 
IANA has created the registry "PIDF-LO Civic Address Considerations 
Registry", according to the following definitions. Furthermore, this 
document registers a civic address considerations document for 
Austrian addresses, as provided in the Appendix of this document, and 
also registers the considerations of RFC 4776 as obsolete. 

6.1. PIDF-LO Civic Address Considerations Registry 

Gebel “Structure 


The IANA registry contains the following fields: 


o Country-Code: either the ISO 3166 alpha-two code of the country to 
which the consideration applies or "other" in case the 
considerations document is not specific to a particular country. 
This field is to be defined by the requestor. 


o Serial Number: a number that uniquely identifies a considerations 
document within a certain "Country-Code" field value. Serial 
Numbers are sequentially assigned by IANA per Country-Code value, 
start at zero, and are never reused. 
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o Reference to specification: this field contains a reference to the 


considerations document. The xref type "rfc" should be used for 
referencing to RFCs, while other documents should use the "uri" 
type. 


o Requestor: the author of the document. 


o Status: one of either "active" or "obsolete". When the document 
is registered by IANA, the status is first set to "active" by 
IANA. Experts may later request changing the status to 
"obsolete", especially if there is an updated version of the 
considerations document available. Authors of considerations 
documents must contact the experts if they wish to change the 
status of the document. 


Note: the combination of Country-Code and Serial Number fields 
uniquely identifies a considerations document in the registry (for 
example, "AT-0", "US-0", "US-1", or "other-0"). 


6.1.2. Registration Template 
For registration of address considerations documents in the registry, 


requesters SHOULD use the following template. The template SHOULD be 
contained in the considerations document itself. 


<record> 
<country> <!-- Country-Code --> </country> 
<serial> <!-- assigned by IANA --> </serial> 
<!-- reference to document --> 


<xref type="uri" data="http://www.example.org/civicaddr/"/> 


<!-- record requesters --> 
<xref type="person" data="John_Doe"/> 
<xref type="person" data="Jane_Dale"/> 


<status> <!-- assigned by IANA --> </status> 
</record> 
<people> 
<person id="John_Doe"> 
<name> <!-- Firstname Lastname --> </name> 
<org> <!-- Organization Name --> </org> 
<uri> <!-- mailto: or http: URI --> </uri> 
<updated> <!-- date format YYYY-MM-DD --> </updated> 
</person> 
<!-- repeat person section for each person --> 
</people> 


Wolf & Mayrhofer Best Current Practice [Page 13] 


RFC 5774 Civic Address Considerations March 2010 


6.1.3. Registry Location 


Approved registrations are published in the IANA registry named 
"PIDF-LO Civic Address Considerations Registry", which is available 
from http://www.iana.org. 


Registrations are sorted by ascending order by the Country-Code and 
by Serial Number within Country-Code values. Registrations with 


Country-Code of "other" are put at the end of the list. 


6.1.4. Registration Procedure 


Following the policies outlined in [RFC5226], new address 
considerations are added to the registry after Expert Review (see 


Section 4.1 in RFC 5226). The Expert will generally check if the 
submitted address considerations conform to the civic address 
guidelines in this document (see Section 4). If in doubt, the Expert 


SHOULD consult the GEOPRIV mailing list or its dedicated successor. 
If possible, the Experts SHOULD check the available documentation on 
which the address consideration is based. 


6.2. Registration Request for Austria 


This document registers the civic address considerations for 
addresses from the official Austrian Building and Habitation 
registry, according to the registration procedure described above. 
The required information is contained in Appendix A. 


6.3. Registration of the Considerations in RFC 4776 as Obsolete 


Since this document updates RFC 4776, the considerations on the 
subdivision Elements in Section 3.4 of RFC 4776 for Canada, Germany, 
Japan, Korea, and the United States are obsolete. The following IANA 
registration records register them in the IANA registry as obsolete. 
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Canada: 

<record> 
<country>CA</country> 
<serial>0</serial> 
<xref type="rfc" data="rfc4776"/> 
<xref type="person" data="Henning_Schulzrinne"/> 
<status>obsolete</status> 

</record> 


<people> 
<person id="Henning_Schulzrinne"> 
<name>Henning Schulzrinne</name> 
<org>Columbia University</org> 
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> 
<updated>2009-01-09</updated> 
</person> 
</people> 


Germany: 

<record> 
<country>DE</country> 
<serial>0</serial> 
<xref type="rfc" data="rfc4776"/> 
<xref type="person" data="Henning_Schulzrinne"/> 
<status>obsolete</status> 

</record> 


<people> 
<person id="Henning_Schulzrinne"> 
<name>Henning Schulzrinne</name> 
<org>Columbia University</org> 
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> 
<updated>2009-01-09</updated> 
</person> 
</people> 


2010 
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Japan: 

<record> 
<country>JP</country> 
<serial>0</serial> 
<xref type="rfc" data="rfc4776"/> 
<xref type="person" data="Henning_Schulzrinne"/> 
<status>obsolete</status> 

</record> 


<people> 
<person id="Henning_Schulzrinne"> 
<name>Henning Schulzrinne</name> 
<org>Columbia University</org> 
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> 
<updated>2009-01-09</updated> 
</person> 
</people> 


Korea: 

<record> 
<country>KR</country> 
<serial>0</serial> 
<xref type="rfc" data="rfc4776"/> 
<xref type="person" data="Henning_Schulzrinne"/> 
<status>obsolete</status> 

</record> 


<people> 
<person id="Henning_Schulzrinne"> 
<name>Henning Schulzrinne</name> 
<org>Columbia University</org> 
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> 
<updated>2009-01-09</updated> 
</person> 
</people> 
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United States: 

<record> 
<country>US</country> 
<serial>0</serial> 
<xref type="rfc" data="rfc4776"/> 
<xref type="person" data="Henning_Schulzrinne"/> 
<status>obsolete</status> 

</record> 


<people> 
<person id="Henning_Schulzrinne"> 
<name>Henning Schulzrinne</name> 
<org>Columbia University</org> 
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> 
<updated>2009-01-09</updated> 
</person> 
</people> 
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Appendix A. Civic Address Considerations Registration for the Austrian 
Building and Habitation Registry 


The Austrian "Gebaeude- und Wohnungsregistergesetz" (building and 
habitation registry law) is the legal basis for the obligation to 
provide a registry of civic addresses, buildings, and their usable 
units (subdivisions of buildings). The registry is operated by 
"Statistik Austria GmbH", a fully governmentally owned company. The 
local administrations of individual townships are responsible for 
keeping records in the registry up to date. 


The data format definition for the individual records is publicly 
available (data access itself is, however, restricted). Hence, a 
uniform address database for the whole of Austria is available. A 
detailed description of the Statistik Austria civic address data 
format is contained in Appendix A.l. 


A.l. Civic Address Format in Austria 


Statistik Austria data describes estates, buildings, and usable units 
[merkmalskatalog]. On a single estate there may be any number of 
buildings. Apartment houses that have more than one staircase are 
split up in separate buildings at every staircase. In every 
building, there may be several usable units. For example, an 
apartment house may have several apartments, counting as separate 
usable units. Moreover, one building may have more than one address 
but will have at least one address. Below, the address Fields for 
estates (Table 1), buildings (Table 2), and usable units (Table 3) 
are shown. 


The ADDCODE, A5, and PCN Elements are optional, and the other 
Elements MUST be used if the data source contains their corresponding 
Fields. The Elements Al and A2 (not listed in the tables) SHOULD 
also be used if data is available. Exception: when using the address 
codes only (access to the codes is necessary for the creator and 
recipient of the location information), just the ADDCODE and country 
Elements are mandatory; the other Elements can be used optionally, of 
course. 
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+------------------------- +------------------------------- +--------- + 
| Statistik Austria name | Explanation | PIDF-LO | 
| | Element | 
+------------------------- $ 4+--------- + 
| Adresscode | address identifier | ADDCODE | 
| | | | 
| Gemeindename, | commune name and identifier | A3 
| Gemeindekennziffer | | | 
| Ortschaftsname, | village name and identifier | A4 | 
| Ortschaftskennziffer | | | 
| | | | 
| Strassenname, | street name and identifier | RD 
| Strassenkennziffer | | | 
| | | | 
Katastralgemeindename, cadastral municipality and A5 
Katastralgemeindenummer identifier 
| | | | 
| Hausnummerntext | text in front of the house | HNO 
| | number | | 
| | | | 
Hausnummer - 1. Teil - first part of the house HNO 
Nummer number, numeric 
| | | | 
| Hausnummer - 1. Teil - | first part of the house | HNO | 
| Buchstabe | number, character | 
| | | | 
Hausnummer - links first and Bis part of HNO 
Verbindungszeichen Teil house number 
| 1 -> Bis | | | 
| | | | 
| Hausnummer - Bis-Nummer | number of Bis part of house | HNO | 
| | number | | 
| Hausnummer - | character of Bis part of | HNO 
| Bis-Buchstabe | house number | 
| | | | 
| Hausnummernbereich | indicates if all house | HNO 
| | numbers specified or just odd | 
| | or even numbers are stated | 
| Postleitzahl | postal code | PC | 
| | | | 
| Postleitzahlengebiet | postal community code | PCN | 
| | | | 
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| Vulgoname | local name 
| Hofname | farm name 
+------------------------- 4+-------------------- OAT 
Table 1: Civic Address Fields for Estates 
$ +-------------------------------- 
Statistik Austria name Explanation 
H==s>==S 535558 iS aS Sas === 252822255225 ==8=55 
| Adresssubcode | address subcode 
| Objektnummer | object code 
Hausnummer - links Bis and second part of 
Verbindungszeichen house number 
| Teil Bis -> Teil 2 | 
| Hausnummer - 2. Teil | second part of the house 
| - Nummer | number, numeric 
| Hausnummer - 2. Teil | second part of the house 
| - Buchstabe | number, character 
| Hausnummer - | links second and third part of 
| Verbindungszeichen | house number 
| Teil 2-> Teil 3 | 
| Hausnummer - 3. Teil | third part of the house 
| - Nummer | number, numeric 
| Hausnummer - 3. Teil | third part of the house 
| - Buchstabe | number, character 
| Gebaeudeunterscheidung | for differentiation of 
| | buildings, e.g. Maierweg 27 
| | Hotel vs. Maierweg 27 
| | Appartmenthaus 
$ 4+------------------- 


+ 


+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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a ee + + + 
| Statistik Austria name | Explanation | PIDF-LO | 
| | | Element | 
+2 + + + 
| Nutzungseinheitenlaufnummer | usable unit code | ADDCODE | 
| | | | 
| Tuernummer | door number | HNO | 
| | | | 
| Topnummer | unit number | HNO | 
| Lagebeschreibung | for verbal description | HNO 
| | | | 
| Lage | describes if the usable | FLR | 
| | unit is in the basement, | 
| | mezzanine, attic floor, | 
(but not the floor 
number) 
| | | | 
| Stockwerk | floor | FIR | 
| | | | 
AZ TE EE CEEE E EENE Pee eee Se ee ee + + 
Table 3: Additional Civic Address Fields for Usable Units 
Note: "floors" in Austria (as in most parts of Europe) are counted 


differently compared to the US. The "1st floor" in Austria is 
actually the floor above the floor at street level (2nd floor in US) 
-- not considering the fact that, in old buildings, there might be 
even more floors between street level and 1st floor, like "mezzanine" 
and "2nd mezzanine". So, an Austrian "1st floor" could well be the 
"Ath floor" according to US nomenclature. 


According to Statistik Austria [adrwarten], 81.5% of Austrian 
addresses are of the simple type Musterstrasse 1 (Musterstrasse is an 
example street name). 5% of all addresses have an additional 
character, like Musterstrasse 1b. 1% of Austrian addresses look like 
Musterstrasse 21A - 23A. For 8% of addresses, an additional 
separator is necessary -- like Musterstrasse 10 Haus 1 Stiege 2, or 
Musterstrasse 20 Gruppe A Reihe 1 Parzelle 13, or Musterstrasse 30 
Weg 1 Parzelle 10. Very seldom, there are so-called special 
addresses (0.03%) -- for example, Musterstrasse gegenueber 3A, 
meaning this address is actually opposite of house number 3A. Rather 
surprisingly, 4.47% of Austrian addresses contain the identifier of 
the estate since no house number is assigned at all -- for example, 
Musterstrasse GNR 1234, or Musterstrasse GNR .12/4 Kirche (this type 
of addresses is common for churches), or a real example in Stockerau: 
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A. 
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2. 


Kolomaniwoerth GNR 1583. This identifier is stored by Statistik 
Austria as Hausnummerntext. Otherwise, one could misinterpret this 


number as a house number, which would be definitely wrong. 


Sample Addresses 


In order to clarify the Austrian civic address format, this section 


provides some exemplary addresses: 


1234 Musterstadt, Hauptstrasse la - 5a Block 1b Haus 2c Stiege 1 


Postleitzahl: 1234 
Stadt: Musterstadt 
Strasse: Hauptstrasse 


Hausnummer - 1. Teil - Nummer: 1 

Hausnummer - 1. Teil - Buchstabe: a 

Hausnummer - Verbindungszeichen Teil 1 -> Bis: - 
Hausnummer - 2. Teil - Nummer: 5 

Hausnummer - 2. Teil - Buchstabe: a 

Hausnummer - Verbindungszeichen Teil Bis -> Teil 2: Block 
Hausnummer - 2. Teil - Nummer: 1 

Hausnummer - 2. Teil - Buchstabe: b 

Hausnummer - Verbindungszeichen Teil 2-> Teil 3: Haus 
Hausnummer - 3. Teil - Nummer: 2 

Hausnummer - 3. Teil - Buchstabe: c 


Gebaeudeunterscheidung: Stiege 1 


1234 Musterstadt, Musterstrasse 13 Hotel 
Postleitzahl: 1234 

Stadt: Musterstadt 

Strasse: Musterstrasse 

Hausnummer - 1. Teil - Nummer: 13 
Gebaeudeunterscheidung: Hotel 


6020 Innsbruck, Anichstrasse vor 35 
Postleitzahl: 6020 

Stadt: Innsbruck 

Strasse: Anichstrasse 
Hausnummerntext: vor ("in front of") 
Hausnummer: 35 


6173 Oberperfuss, Riedl 3097 (Pfarrkirche) 

Postleitzahl: 6173 

Stadt: Oberperfuss 

Strasse: Riedl 

Hausnummerntext: 3097 

(since the estate identifier is 81305 3097, where 81305 is the 
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Katastralgemeindenummer (cadastral municipality), and no house 
number is assigned) 
Vulgoname: Pfarrkirche 


A.3. Address Codes in Austria 


Statistik Austria registers 4 codes: Adresscode, Adresssubcode, 
Objektnummer, and the Nutzungseinheitenlaufnummer. The Adresscode (7 
digits) is a unique code for an address in Austria. The 
Adressregister maps the Adresscode to the civic address. If there is 
a building located at an address, there is also an Adresssubcode (3 
digits) assigned. Every building at an address has its own 
Adresssubcode (assigned sequentially starting with 001, 002, 003, and 
so on) in order to distinguish between buildings at the same address. 
Furthermore, every building located in Austria has its own unique 
code, the Objektnummer (7 digits). This code identifies the building 
independent of the Adresscode. That’s because addresses are subject 
to change while the building may persist. To differentiate multiple 
usable units inside a building, the Nutzungseinheitenlaufnummer (4 
digits) is used. This code is also assigned in sequential order for 
each building. 


Besides, every address and building is geocoded by Statistik Austria. 
Hence, if every PIDF-LO would carry data in the format of Statistik 
Austria and if every PSAP would use the database of Statistik Austria 
for mapping, a time-saving, definite mapping without irregularities 
could be achieved. 


Besides these codes, Statistik Austria maintains reference numbers 
for communes, localities, or streets, to mention just a few. 


A.4. Austrian Addresses in PIDF-LO 
The following subsections define the mapping procedure. 
A.4.1. Country 


The country Element for Austria must be set to AT, since this is the 
ISO 3166-1 [ISO3166-1] alpha-2 code for Austria. 


<country>AT</country> 


The usage of the ISO 3166 code is demanded by RFC 4119 [RFC4119], and 
RFC 5139 [RFC5139] proposes to use uppercase characters only. 
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A.4.2. Country Subdivisions Al-A6 


Al province (Bundesland), Section A.4.2.1 

A2 political district name or identifier (politischer Bezirk), 
Section A.4.2.2 

A3 commune name or identifier (Gemeinde), Section A.4.2.3 

A4 village name or identifier (Ortschaft), Section A.4.2.4 

A5 cadastral municipality name or identifier (Katastralgemeindename 
or Katastralgemeindenummer), Section A.4.2.5 


Element A6 must not be used. 


Last, there is an exception to mention that concerns the Austrian 
capital, Vienna (Wien). The city of Vienna is equal to its political 
district and even the province is called Vienna. Nevertheless, 
Vienna is separated in 23 districts within the same political 
district. Consequently, an address in Vienna would look like: 


<country>AT</country> 
<Al>Wien</A1> 

<A2>Wien</A2> 

<A3>Wien</A3> 

<A4>Favoriten</A4> or <A4>10<A4> 
<A5>Inzersdorf Stadt<A5> 


The Element A4, holding the city division, can hold the name or the 
number of the district. 


A.4.2.1. Al Element 


As proposed in RFC 5139 [RFC5139], for the PIDF-LO Element Al, the 
second part of ISO 3166-2 [ISO3166-2] can be used. However, in 
Austria it is also common to write out the names of the states. 
Table 4 shows the possible values of the Al Element for Austrian 
states. 
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$ O E AA O O O + 
| Bundesland | second part of ISO 3166-2 code | 
AZ O $ O O O + 
| Burgenland | 1 | 
| | | 
| K=U+00E4rnten | 2 | 
| | | 
| Nieder=U+00F6sterreich | 3 

| Ober=U+00F6sterreich | 4 

| | | 
| Salzburg | =) | 
| | | 
| Steiermark | 6 | 
| | | 
| Tirol | 7 | 
| Vorarlberg | 8 | 
| | | 
| Wien | 9 | 
tee ASAS EA E SA AA TE + 


Table 4: Al Element Format for Austria 
(Note: values are shown in UTF-8, which is recommended to be used for 
PIDF-LO.) 


A.1.2.2. A2 Element 


Names of the Austrian political districts are available at Statistik 
Austria [bezirke]. These names, the unique code for the political 
district, or both can be used for the A2 Element. If the content of 
the A2 Element is numeric, obviously the code is provided (there is 
no political district in Austria with a number in its name). In case 
both the name and the code are provided, they are separated by a 
semicolon and the name must be listed first. 


The district of "Bruck an der Leitha" could be represented by: 
<A2>Bruck an der Leitha<A2> 


or 
<A2>307</A2> 


or 
<A2>Bruck an der Leitha;307</A2> 
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A.4.2.3. A3 Element 


The Element A3 holds the Gemeindename (commune name), the identifier 
of the Gemeinde, or both separated by a semicolon (the name must be 
listed first). If the content of the A3 Element consists of a number 
only, it is obvious that just the identifier is provided. Statistik 
Austria maintains a table with the Gemeindenamen and identifiers 
[gemeinden], which must be used as the content for the A3 Element; no 
other spelling is allowed. 


Sample: 
<A3>Neusiedl am See</A3> 


or 
<A3>10713</A3> 


or 
<A3>Neusiedl am See; 10713</A3> 


A.4.2.4. A4 Element 


The Element A4 holds the Ortschaftsname (village name), the 
Ortschaftskennziffer (the identifier), or both separated by a 
semicolon (the name must be listed first). If the content of the A4 
Element consists of a number only, it is obvious that just the 
identifier is provided, since there are no Ortschaftsnamen in Austria 
that contain a number. Statistik Austria maintains a table with the 
Ortschaftsnamen and identifiers [ortschaften], which must be used as 
the content for the A4 Element; no other spelling is allowed. 


Sample: 
<A4>Wilfleinsdorf</A4> 


or 
<A4>03448</A4> 


or 
<A4>Wilfleinsdorf; 03448</A4> 


A.4.2.5. A5 Element 
The Element A5 holds the Katastralgemeindename (cadastral 


municipality), the Katastralgemeindenummer (the identifier), or both 
separated by a semicolon (the name must be listed first). If the 
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content of the A5 Element consists of a number only, it is obvious 
that just the identifier is provided, since there are no 
Katastralgemeindenamen in Austria that contain a number. 

Sample (Vienna, Fuenfhaus): 


<A5>Oberbaumgarten</A5> 


or 
<A5>1208</A5> 


or 
<A5>Oberbaumgarten; 1208</A5> 


A.4.3. Road and Street Names 
The PIDF-LO Element RD holds the complete street name, including the 
street suffix. No abbreviations are allowed. No other Elements are 
needed for streets and must not be used. 

A.4.4. House Numbers 
Statistik Austria lists 14 data Fields related to the house number of 


a building plus another 5 Fields for distinction of different usable 
units inside a building (including the floor, which has a separate 


Element in PIDF-LO). Unfortunately, PIDF-LO only defines a single 
house number Element (HNO, numeric part only) and house number suffix 
Element (HNS). Therefore, this section defines a mapping in order to 


accommodate all data: all house number data is concatenated into a 
single HNO Element, even though it is expected to hold numeric part 
only. 


In order to allow automatic procession of the HNO Element, it is 
necessary to use a semicolon as a delimiter symbol (Austrian house 


numbers do not contain semicolons). The house number parts MUST be 
provided in the order in which they are listed by the Statistik 
Austria document [merkmalskatalog]. For user-interface 


representation, the semicolon-separated format can be transformed by 
replacing semicolons by spaces (multiple spaces should be combined) 
and no space should be present between a numeric part of a house 
number and its related character. 


It is not allowed to use the HNS Element for Austrian addresses, 
since there are addresses that do not have just a single suffix. 


Wolf & Mayrhofer Best Current Practice [Page 27] 


RFC 5774 Civic Address Considerations March 2010 


A. 


A. 


The house number "vor 1 - 1A" (consisting of a house number text 
"vor", first part of the house number numeric "1", "-" as the link of 
the first and Bis part, "1" as house number Bis part numeric, "A" as 
character of the Bis part) would be mapped to: 


4.5. Local Names 


NAM: contains the Vulgoname (local name); multiple local names are 
separated by a semicolon (if applicable). 


LMK: contains the farm name (just one name possible) (if applicable). 


LOC: can be used without restriction for additional location 
information (as per RFC 4119). 


-4.6. Floors 


The floor Element may contain numbers or text describing the floor. 
The first floor (<FLR>1</FLR>) is the floor above the floor at street 
level. The floor at street level is <FLR>EG</FLR> or <FLR>0</FLR>. 
Other floors may have names like mezzanine, for example. The 
Statistik Austria data Fields Lage and Stockwerk are concatenated if 
necessary. 


4.7. Additional Code Element 


The Element additional code may be used to hold the codes provided by 
Statistik Austria. There is an Adresscode, Adresssubcode, 
Objektnummer, and a Nutzungseinheitenlaufnummer. These unique codes 
identify the location. Actually, these codes alone would be enough 
but require that the location recipient has access to the database of 
Statistik Austria. 


If the additional code in a PIDF-LO document is going to hold the 
codes from Statistik Austria, the following format should be used: 


<ADDCODE>AdrCD=1234567; AdrsubCD=123; 
Ob jNr=2333211;NtzLnr=0001</ADDCODE> 


It is not necessary to provide all codes, but there are some 
restrictions: the Adresssubcode cannot be used without an Adresscode. 
More restrictions are defined by Statistik Austria. By setting the 
country Element to AT (see Section 4.2.1), indicating an Austrian 
address, the Additional Code Element is expected to hold codes from 
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Statistik Austria only. When creating PIDF-LO documents using 
address codes by Statistik Austria, the country and ADDCODE Elements 
are mandatory. 


A.4.8. Other Elements 


The Elements PC and PCN can hold the data form Statistik Austria, the 
POBOX can be used if the post assigned a post office box. At least 
the PC Element should be present. 


PC: Postleitzahl (postal code) 
PCN: Postleitzahlengebiet (postal community name) 
POBOX: Postfach 


The Elements UNIT, ROOM, SEAT, PLC, and BLD may be used without 
further restriction. 


A.4.9. Elements Not to Be Used 


AG 

STS 

HNS 

PRD 

POD 
RDBR 
RDSUBBR 
PRM 

POM 


A.5. Example 


This section shows an example mapping of an Austrian address to 
PIDF-LO. 


Address: 
Bundesland: Wien 


Politischer Bezirk: Wien 
Gemeindename: Wien 


9. Bezirk 

Strasse: Lazarettgasse 

Hausnummer - 1. Teil - Nummer: 13 
Hausnummer - 1. Teil - Buchstabe: A 


Hausnummer - Verbindungszeichen Teil 1-Bis: - 
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Hausnummer - Bis-Nummer: 13 
Hausnummer - Bis-Buchstabe: C 
Postleitzahl: 1090 
PIDF-LO: 


<?xml version="1.0" encoding="UTF-8" ?> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
xmlns:gp="urn:ietf:params:xml:ns:pidf:geoprivl0" 
xmlns:cl="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
entity="pres:123@examplehost"> 
<tuple id="abcd123456"> 


<status> 


<gp:geopriv> 
<gp:location-info> 
<cl:civicAddress xml:lang="de"> 


<cl 
<cl 
<cl 
<cl 
<cl 
<cl 


<cl 


:country>AT</cl:country> 
:Al>Wien</cl:A1> 
:A2>Wien</cl:A2> 
:A3>Wien</cl:A3> 
:A4>9</c1l:A4> 
:RD>Lazarettgasse</cl:RD> 
<cl: 
:¿PC>1090</c1:PC> 


</cl:civicAddress> 
</gp:location-info> 
<gp:usage-rules> 
<gp:retransmission-allowed>yes</gp:retransmission-allowed> 
<gp:retention-expiry>2009-11-10T12:00:002</gp:retention-expiry> 
</gp:usage-rules> 
</gp:geopriv> 


</status> 


<timestamp>2009-02-09T12:00:002</timestamp> 


</tuple> 
</presence> 


A.6. IANA Registration Record 


<record> 


<country>AT</country> 
<serial>0</serial> 


<!-- reference to document --> 
<xref type="rfc" data="rfc5774"/> 


<!-- record requesters --> 
<xref type="person" data="Alexander_Mayrhofer"/> 
<xref type="person" data="Karl_Heinz_Wolf"/> 
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<status>active</status> 
</record> 


<people> 
<person id="Alexander_Mayrhofer"> 
<name>Alexander Mayrhofer</name> 
<org>nic.at GmbH</org> 
<uri>mailto:alexander.mayrhofer@nic.at</uri> 
<updated>2009-01-09</updated> 
</person> 
<person id="Karl_Heinz Wolf"> 
<name>Karl Heinz Wolf</name> 
<org>nic.at GmbH</org> 
<uri>mailto:karlheinz.wolf@nic.at</uri> 
<updated>2009-01-09</updated> 
</person> 
</people> 
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